https://metaplay.io logo
When to implement IModel
# questions-and-feedback
d
Hi, I have created a custom entity following Custom entities guide: https://docs.metaplay.io/game-server-programming/how-to-guides/custom-server-entities.html The model in the guide extends ISchemaMigratable. I am seeing a lot of models that implement IModel and I'm wonding if you could give some guidance as to when you would implement IModel? For example there is GetEntityStateAsync in GameAdminApiController which assumes my model will be extending IModel. Thanks Andre
j
Short answer: IModel is for replicating over network. ISchemaMigratable is sufficient if replication is not needed, as in this case where we have a server-only entity. Long answer: I'll update the doc comment for IModel in the next release to contain: Interface for all game Model classes. A model is a state of an object that can be replicated over network. The (shared subset of the) model is primarily mutated with two mechanisms - actions () and ticks () which mutate the state deterministically. In addition to the execution model, the Model defines a GameConfig (see and the execution always happens in respect to this Game Config. In practical terms, when the Model is deserialized, a Game Config is chosen, and all Game Config References in the Model (see ) are hydrated to reference items in that particular game config version. When Actions or Ticks mutate the model, they may use these GameConfig references. Since the Game Config is replicated over network too, the execution is deterministic but also configurable. Finally, after the execution model and game config, an also contains . Logic version defines the version of the model such that multiple Model States and Execution models can be supported at the same time. In practical terms, Logic Version allows Server to provide backwards-compatible changes to game logic and game state: The game logic can be altered by simply checkign the version in actions and ticks, and the state can be altered with and attributes. If you do NOT need execution model that cab be replicated over network, consider using plain .
W.r.t.
GetEntityStateAsync
that's a good point. Currently it only works for
PersistedMultiplayerEntityActorBase
and Player actor, or anything that manually implements InternalEntityStateRequest. Due to an implementation detail, we ended up carrying IModels instead of ISchemaMigratables in the InternalEntityStateResponse. So it's not by design but more like an oversight. I think what we would want here is that: * GetEntityStateAsync it will be changed to return ISchemaMigratable. * Server-Entities should not need to manually implement InternalEntityStateRequests to be eligible for GetEntityStateAsync I've added this to a todo list, but I must warn you the priority is low and there are many competing things on the list too. If this is a critical for you, you can work around it by creating custom yor own InternalEntityStateRequest / Response and manually handling that in the actor and on call-site you EntityAsk manually.
d
Hi Jarkko, Much appreciate the replies. I understand IModel purpose now. wrt GetEntityState it's not at all urgent. I've implemented my own EntityAskHandler. I'm not doing anything complicated but just trying to get my head around how I should be doing things and seeing many things using IModel got me wondering if I was missing something. you've clarified it for me now.